| PNG | |
A PNG image with an 8-bit transparency channel (top). The same image is overlaid onto a checkered background (bottom), typically used in graphics software to indicate transparency. |
|
| Filename extension | .png |
|---|---|
| Internet media type | image/png |
| Type code | PNGfPNG |
| Uniform Type Identifier | public.png |
| Magic number | 89 50 4e 47 0d 0a 1a 0a |
| Developed by | PNG Development Group (donated to W3C) |
| Initial release | October 1, 1996 |
| Type of format | lossless bitmap image format |
| Extended to | APNG, JNG and MNG |
| Standard(s) | ISO/IEC 15948,[1] IETF RFC 2083 |
| Open format? | Yes |
Portable Network Graphics (PNG /ˈpɪŋ/[2]) is a bitmapped image format that employs lossless data compression. PNG was created to improve upon and replace GIF (Graphics Interchange Format) as an image-file format not requiring a patent license. The initialism PNG can also be interpreted as a recursive initialism for "PNG's Not GIF".[2]
PNG supports palette-based images (with palettes of 24-bit RGB or 32-bit RGBA colors), grayscale images (with or without alpha channel), and full-color non-palette-based RGB[A] images (with or without alpha channel). PNG was designed for transferring images on the Internet, not for professional-quality print graphics, and therefore does not support non-RGB color spaces such as CMYK.
PNG files nearly always use file extension PNG or png and are assigned MIME media type image/png; it was approved for this use by the Internet Engineering Steering Group on October 14, 1996.[3] PNG was published as an ISO/IEC standard in 2004.[1]
Contents |
The motivation for creating the PNG format was in early 1995, after it became known that the Lempel–Ziv–Welch (LZW) data compression algorithm used in the Graphics Interchange Format (GIF) format was patented by Unisys. There were also other problems with the GIF format that made a replacement desirable, notably its limit of 256 colors at a time when computers able to display far more than 256 colors were growing common. Although GIF allows for animation, it was decided that PNG should be a single-image format. A companion format called Multiple-image Network Graphics (MNG) has been defined for animation, whereas a competing format, Animated Portable Network Graphics (APNG), supports backward-compatibility with PNG (which MNG does not).
A January 1995 precursory discussion thread, on the usenet newsgroup "comp.graphics" with the subject Thoughts on a GIF-replacement file format, had many propositions, which would later be part of the PNG file format. In this thread, Oliver Fromme, author of the popular DOS JPEG viewer QPEG, proposed the PING name, meaning PING is not GIF, and also the PNG extension.[4]
The original PNG specification was authored by an ad-hoc group of computer graphics experts and enthusiasts. Discussions and decisions about the format were done exclusively via email. The original authors listed on RFC 2083 are:[5]
A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A; the decimal values are 137 80 78 71 13 10 26 10. Each of the header bytes is there for a specific reason:[6]
| Bytes | Purpose |
|---|---|
89 |
Has the high bit set to detect transmission systems that do not support 8 bit data and to reduce the chance that a text file is mistakenly interpreted as a PNG, or vice versa. |
50 4E 47 |
In ASCII, the letters PNG, allowing a person to identify the format easily if it is viewed in a text editor. |
0D 0A |
A DOS-style line ending (CRLF) to detect DOS-Unix line ending conversion of the data. |
1A |
A byte that stops display of the file under DOS when the command type has been used—the end-of-file character |
0A |
A Unix-style line ending (LF) to detect Unix-DOS line ending conversion. |
After the header comes a series of chunks, each of which conveys certain information about the image. Chunks declare themselves as critical or ancillary, and a program encountering an ancillary chunk that it does not understand can safely ignore it. This chunk-based storage layer structure, similar in concept to a container format, is designed to allow the PNG format to be extended while maintaining compatibility with older versions—it provides forward compatibility, and this same file structure (with different signature and chunks) is used in the associated MNG, JNG, and APNG formats.
A chunk consists of four parts: length (4 bytes), chunk type/name (4 bytes), chunk data (length bytes) and CRC (cyclic redundancy code/checksum; 4 bytes).
| Length | Chunk type | Chunk data | CRC |
|---|---|---|---|
| 4 bytes | 4 bytes | Length bytes | 4 bytes |
Chunks are given a four letter case sensitive ASCII type/name; compare FourCC. The case of the different letters in the name (bit 5 of the numeric value of the character) is a bit field that provides the decoder with some information on the nature of chunks it does not recognize.
The case of the first letter indicates if the chunk is critical or not. If the first letter is uppercase, the chunk is critical; if not, the chunk is ancillary. Critical chunks contain information that is necessary to read the file. If a decoder encounters a critical chunk it does not recognize, it must abort reading the file or supply the user with an appropriate warning.
The case of the second letter indicates if the chunk is "public" (either in the specification or the registry of special purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other (although two private chunk names could conflict).
The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion. Decoders should treat a chunk with a lower case third letter the same as any other unrecognised chunk.
The case of the fourth letter indicates if a chunk is safe to copy by editors that do not recognize it. If lowercase, the chunk may be safely copied regardless of the extent of modifications to the file. If uppercase, it may only be copied if the modifications have not touched any critical chunks.
A decoder must be able to interpret these to read and render a PNG file.
IHDR must be the first chunk; it contains the image's width, height, and bit depth.[7]PLTE contains the palette; list of colors.IDAT contains the image, which may be split among multiple IDAT chunks. Doing so increases filesize slightly, but makes it possible to generate a PNG in a streaming manner.IEND marks the image end.The PLTE chunk is essential for color type 3 (indexed color). It is optional for color types 2 and 6 (truecolor and truecolor with alpha) and it must not appear for color types 0 and 4 (grayscale and grayscale with alpha).
Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information. PNG also supports color management through the inclusion of ICC color space profiles.[8]
The lowercase first letter in these chunks indicates that they are not needed for the PNG specification. The lowercase last letter in some chunks indicates that they are safe to copy, even if the application concerned does not understand them.
| Bits per pixel | Bits per channel | |||||
|---|---|---|---|---|---|---|
| Color option | Channels | 1 | 2 | 4 | 8 | 16 |
| Indexed | 1 | 1 | 2 | 4 | 8 | |
| Grayscale | 1 | 1 | 2 | 4 | 8 | 16 |
| Grayscale & alpha | 2 | 16 | 32 | |||
| Truecolor | 3 | 24 | 48 | |||
| Truecolor & alpha | 4 | 32 | 64 | |||
PNG images can either use palette-indexed color or be made up of one or more channels (numerical values directly representing quantities about the pixels). When there is more than one channel in an image all channels have the same number of bits allocated per pixel (known as the bit depth of the channel). Although the PNG specification always talks about the bit depth of channels, most software and users generally talk about the total number of bits per pixel (sometimes also referred to as bit depth or color depth). Since multiple channels can affect a single pixel, the number of bits per pixel is often higher than the number of bits per channel, as shown in the illustration at right.
The number of channels will depend on whether the image is grayscale or color and whether it has an alpha channel. PNG allows the following combinations of channels, called the color type.
The color type is specified in the color type field, which is a bit field, as explained in the table below at right. Not all combinations are valid, however: there is no indexed grayscale, which would be color types 1 and 5; transparency in palette images is indicated by the presence of a tRNS chunk, not a separate channel, so there is no color type 7.
| Color type |
Name | Binary | Masks | |||
|---|---|---|---|---|---|---|
| A | C | P | ||||
| 0 | Grayscale | 0 | 0 | 0 | 0 | |
| 1 | Indexed grayscale | 0 | 0 | 0 | 1 | palette |
| 2 | Truecolor | 0 | 0 | 1 | 0 | color |
| 3 | Indexed | 0 | 0 | 1 | 1 | palette |
| 4 | Grayscale & alpha | 0 | 1 | 0 | 0 | alpha |
| 5 | Indexed grayscale & alpha | 0 | 1 | 0 | 1 | palette |
| 6 | Truecolor & alpha | 0 | 1 | 1 | 0 | color |
| 7 | Indexed & alpha | 0 | 1 | 1 | 1 | color | palette |
With indexed color images, the palette is always stored in RGB at a depth of 8 bits per channel (24 bits per palette entry). Additionally, an optional array of 8-bit alpha values of the palette entries may be included. The palette must not have more entries than the image bit depth allows for, but it may have fewer (for example, if an image only uses 90 colors then it does not need palette entries for all 256 colors).
Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; grayscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats, but many image editors can only produce a small subset of them.
PNG offers a variety of transparency options. With truecolor and grayscale images either a single pixel value can be declared as transparent or an alpha channel can be added (enabling any percentage of partial transparency to be used). For paletted images, alpha values can be added to palette entries. The number of such values stored may be less than the total number of palette entries, in which case the remaining entries are considered fully opaque.
The scanning of pixel values for binary transparency is supposed to be performed before any color reduction to avoid pixels becoming unintentionally transparent. This is most likely to pose an issue for systems that can decode 16 bits per channel images (as they must to be compliant with the specification) but only output at 8 bits per channel (the norm for all but the highest end systems).
PNG uses a 2-stage compression process:
PNG uses a non-patented lossless data compression method known as DEFLATE, which is the same algorithm used in the zlib compression library.
Before DEFLATE is applied, the data is precompressed, via a prediction method: a single filter method is used for the entire image, while for each image line, a filter type is chosen that transforms the data so that it is hopefully more easily compressed.[11]
There is only one filter method in the current PNG specification (denoted method 0), and thus in practice the only choice is which filter type to apply to each line. For this method, the filter predicts the value of each pixel based on the values of previous neighboring pixels, and subtracts the predicted color of the pixel from the actual value, as in DPCM. An image line filtered in this way is often more compressible than the raw image line would be, especially if it is similar to the line above, since the differences from prediction will generally be clustered around 0, rather than spread over all possible image values. This is particularly important in relating separate rows, since DEFLATE has no understanding that an image is a 2D entity, and instead just sees the image data as a stream of bytes.
There are five filter types for filter method 0; each type predicts the value of each byte (of the image data before filtering) based on the corresponding byte of the pixel to the left (A), above (B), above and to the left (C) or some combination thereof, and encodes the difference between the predicted value and the actual value. Filters are applied to byte values, not pixels; pixel values may be one or two bytes, or several values per byte, but never cross byte boundaries. The filter types are:[12]
| Type byte | Filter name | Predicted value |
|---|---|---|
| 0 | None | Zero (so that the raw byte value passes through unaltered) |
| 1 | Sub | Byte A (to the left) |
| 2 | Up | Byte B (above) |
| 3 | Average | Mean of bytes A and B, rounded down |
| 4 | Paeth | A, B, or C, whichever is closest to p = A + B − C |
The Paeth filter is based on an algorithm by Alan W. Paeth.[13] Compare to the version of DPCM used in lossless JPEG, and to the discrete wavelet transform using 1×2, 2×1, or (for the Paeth predictor) 2×2 windows and Haar wavelets.
Compression is further improved by choosing filter types adaptively on a line-by-line basis. This improvement, and a heuristic method of implementing it commonly used by PNG-writing software, were created by Lee Daniel Crocker, who tested the methods on many images during the creation of the format;[14] the choice of filter is a component of file size optimization, as discussed below.
If interlacing is used, each stage of the interlacing is filtered separately, meaning that the image can be progressively rendered as each stage is received; however, interlacing generally makes compression less effective.
PNG offers an optional 2-dimensional, 7-pass interlacing scheme—the Adam7 algorithm. This is more sophisticated than GIF's 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer, particularly if interpolation algorithms such as bicubic interpolation are used.[15]
However, the 7-pass scheme tends to reduce the data's compressibility more than simpler schemes.
PNG itself does not support animation at all. MNG is an extension to PNG that does; it was designed by members of the PNG Group. MNG shares PNG's basic structure and chunks, but it is significantly more complex and has a different file signature, which automatically renders it incompatible with standard PNG decoders.
The complexity of MNG led to the proposal of APNG by developers of the Mozilla Foundation. It is based on PNG, supports animation and is simpler than MNG. APNG offers fallback to single-image display for PNG decoders that do not support APNG. However, neither of these formats is currently widely supported. APNG is supported in Firefox 3.0 and Opera 9.5.[16] The PNG Group decided in April 2007 not to embrace APNG.[17] Several alternatives were under discussion, ANG, aNIM/mPNG, “PNG in GIF” and its subset “RGBA in GIF”.[18]
PNG images are less widely supported by older browsers. In particular, IE6 has limited support for PNG).[20] As users adopt newer browsers, this becomes less of an issue.
JPEG (Joint Photographic Experts Group) format can produce a smaller file than PNG for photographic (and photo-like) images, since JPEG uses a lossy encoding method specifically designed for photographic image data, which is typically dominated by soft, low-contrast transitions, and an amount of noise or similar irregular structures. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize with negligible gain in quality. By contrast, when storing images that contain text, line art, or graphics – images with sharp transitions and large areas of solid color – the PNG format can compress image data more than JPEG can, and without the noticeable visual artifacts which JPEG produces around high-contrast areas. Where an image contains both sharp transitions and photographic parts a choice must be made between the two effects. Note that JPEG does not support transparency.
Because JPEG uses lossy compression, it suffers from generation loss, where repeatedly encoding and decoding an image progressively loses information and degrades the image. Because PNG is lossless, it is a suitable format for storing images to be edited. While PNG is reasonably efficient when compressing photographic images, there are lossless compression formats designed specifically for photographic images, lossless JPEG 2000 and Adobe DNG (Digital negative) for example. However these format are either not widely supported or proprietary. An image can be saved into JPEG format for distribution so that the single pass of JPEG encoding will not noticeably degrade the image.
The PNG specification does not include a standard for embedded Exif image data from sources such as digital cameras. TIFF, JPEG 2000, and DNG support EXIF data.
Early web browsers did not support PNG images, JPEG and GIF were the main image formats. JPEG was commonly used when exporting images containing gradients for web pages, because of GIF's limited color depth. However, JPEG compression causes a gradient to blur slightly. A PNG file will reproduce a gradient as accurately as possible for a given bit depth, while keeping the file size small. PNG became the optimal choice for small gradient images as web browser support for the format improved.
JPEG-LS is a "near-lossless" image format by the Joint Photographic Experts Group, though far less widely known and supported than the other lossy JPEG format discussed above. It is directly comparable with PNG, and has a standard set of test images.[21] On the Waterloo Repertoire ColorSet, a standard set of test images (unrelated to the JPEG-LS conformance test set), JPEG-LS generally performs better than PNG, by 10–15%, but on some images PNG performs substantially better, on the order of 50–75%.[22] Thus, if both of these formats are options and file size is an important criterion, they should both be considered, depending on the image.
Tagged Image File Format (TIFF) is a format that incorporates an extremely wide range of options. While this makes TIFF useful as a generic format for interchange between professional image editing applications, it makes adding support for it to applications a much bigger task and so it has little support in applications not concerned with image manipulation (such as web browsers). It also means that many applications can read only a subset of TIFF types, creating more potential user confusion.
The most common general-purpose, lossless compression algorithm used with TIFF is Lempel–Ziv–Welch (LZW). This compression technique, also used in GIF, was covered by patents until 2003. There is a TIFF variant that uses the same compression algorithm as PNG uses, but it is not supported by many proprietary programs. TIFF also offers special-purpose lossless compression algorithms like CCITT Group IV, which can compress bilevel images (e.g., faxes or black-and-white text) better than PNG's compression algorithm.
Popular graphics programs which support the PNG format include Adobe Photoshop, Corel's Photo-Paint and Paint Shop Pro, the GIMP, GraphicConverter, Helicon Filter, Inkscape, IrfanView, Pixel image editor, Paint.NET and Xara Photo & Graphic Designer. Some programs bundled with popular operating systems which support PNG include Microsoft's Paint and Apple's iPhoto and Preview, with the GIMP also often being bundled with popular Linux distributions.
Adobe Fireworks (formerly by Macromedia) uses PNG as its native file format, allowing other image editors and preview utilities to view the flattened image. However, Fireworks by default also stores meta data for layers, animation, vector data, text and effects. Such files should not be distributed directly. Fireworks can instead export the image as an optimized PNG without the extra meta data for use on web pages, etc.[23]
Some image processing programs have PNG compression problems, mainly related to lack of full implementation of the PNG compressor library. These include:
Adobe's Fireworks is sometimes placed in this category, but its difficulties are less severe than the other entries. The confusion stems from a misunderstanding of the mechanics of its Save format: though PNGs, the intermediate images produced by that option include large, private chunks containing complete layer and vector information, which allows further, lossless editing. Properly saved with the Export option, Fireworks' PNGs are competitive with those produced by other image editors, but are no longer editable as anything but flattened bitmaps. Fireworks is unable to save size-optimized vector-editable PNGs.
PNG support first appeared in Internet Explorer 4.0b1 and in Netscape 4.04.[24]
Despite calls by the Free Software Foundation[25] and the World Wide Web Consortium (W3C),[26] tools such as gif2png,[27] and campaigns such as Burn All GIFs,[28] PNG adoption on websites has been fairly slow due to late and buggy support in Internet Explorer, particularly regarding transparency.[29]
GIF is found to be in use more than PNG for a few reasons:
PNG compatible browsers include: Apple Safari, Google Chrome, Mozilla Firefox, Opera, Camino, Internet Explorer 7 (still numerous issues),[30] Internet Explorer 8 (still some issues), Internet Explorer 9 and many others. For the complete comparison, see Comparison of web browsers (Image format support).
However, versions of Internet Explorer (Windows) below 9.0 have numerous problems which prevent it from correctly rendering PNG images.[30]
PNG icons have been supported in most distributions of Linux since at least 1999, in desktop environments such as GNOME.[42] In 2006, PNG icons were introduced into Microsoft Windows, in Windows Vista.[43] PNG icons are supported in AROS, Mac OS X and MorphOS as well.
PNG file size can vary significantly depending on how it is encoded and compressed; this is discussed and a number of tips are given in PNG: The Definitive Guide.[22]
Compared to GIF files, a PNG file with the same information (256 colors, no ancillary chunks/metadata), compressed by a good compressor will often be smaller than GIF. Depending on the file and the compressor, PNG may range from somewhat smaller (10%) to significantly smaller (50%) to somewhat larger (5%), but is rarely significantly larger [22] for large images. This is attributed to the performance of PNG's DEFLATE compared to GIF's LZW, and because the added precompression layer of PNG's predictive filters take account of the 2-dimensional image structure to further compress files; as filtered data encodes differences between pixels, they will tend to cluster closer to 0, rather than being spread across all possible values, and thus be more easily compressed by DEFLATE.[22]
PNG files vary in size due to a number of factors:
There is thus a filesize trade-off between high color depth, maximal metadata (including color space information, together with information that does not affect display), interlacing, and speed of compression, which all yield large files, with lower color depth, fewer or no ancillary chunks, no interlacing, and tuned but computationally intensive filtering and compression. For different purposes one will choose different trade-offs: a maximal file may be best for archiving and editing, while a stripped down file may be best for use on a website, and similarly fast but poor compression is preferred when repeatedly editing and saving a file, while slow but high compression is preferred when a file is stable: when archiving or posting. Interlacing is a trade-off: it dramatically speeds up early rendering of large files (improves latency), but may increase file size (decrease throughput) for little gain, particularly for small files.[22]
Image editing software varies in its treatment of PNGs.
Because GIF is de facto limited to 256 colors (GIF87a Standard), image editors must automatically reduce the color depth when saving an image in GIF format. Often, when people save the same truecolor image as PNG and GIF, they see that the GIF is smaller, and do not realize that this is due to the color depth reduction, and that it is possible to create a 256-color PNG that has identical quality to the GIF with a smaller file size. Further, some tools may automatically create PNG files as 24-bit, even if the source image is 8-bit, bloating the file.[22] This leads to the misconception that PNG files are larger than equivalent GIF files.
Some versions of Adobe Photoshop, CorelDRAW and MS Paint provide poor PNG compression effort, further fueling the idea that PNG is larger than GIF. Many graphics programs (such as Apple's Preview software) save PNGs with large amounts of metadata and color-correction data that are generally unnecessary for Web viewing. Unoptimized PNG files from Adobe Fireworks are also notorious for this since they contain options to make the image editable in supported editors. Also CorelDRAW (at least version 11) sometimes produces PNGs which cannot be opened by Internet Explorer (versions 6–8).
Adobe Photoshop's performance on PNG files has improved in the CS Suite when using the Save For Web feature (which also allows explicit PNG/8 use).
Various tools are available for optimizing PNG files; they do this by:
As some tools are PNG-specific, while others only optimize DEFLATE, in general one must use a combination of 2 tools in sequence for optimal compression: one which optimizes filters (and removes ancillary chunks), and one which optimizes DEFLATE. Most commonly, OptiPNG is used for the first (non-DEFLATE) step, and either of AdvanceCOMP or PNGOUT is used for the DEFLATE step.
For removing ancillary chunks, pngcrush and PNGOUT have the ability to remove all color correction data from PNG files (gamma, white balance, ICC color profile, standard RGB color profile). This often results in much smaller file sizes. The following command line options achieve this with pngcrush:
pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png
For optimizing filters, OptiPNG and pngcrush are both open source software optimizers that run from a Unix command line or a Windows Command Prompt, and effectively reduce the size of PNG files. OptiPNG was based on pngcrush and effectively supersedes it, by iterating over a wider range of compression parameters and performing trials in memory for faster execution,[44] as well as performing automatic bit depth, color type and color palette reduction where possible.
AdvanceCOMP advdef and Ken Silverman's PNGOUT and Glenn Randers-Pehrson's pngcrush and Image::Pngslimmer employ DEFLATE compression algorithms that are more exhaustive and produce smaller files than the reference implementation, zlib, that is used by the other compressors.
Wrapper tools that simplify this workflow include: ImageOptim, a GUI front-end for Mac OS X; Kashmir Web Optimizer- GUI front-end for Windows; imgopt, a command-line shell script that also losslessly optimizes JPEG images; and Smush.it, an image-optimizing web service.
The littleutils are another open-source package, containing a wrapper script called opt-png that uses pngcrush and a variant of pngrewrite to reduce bit-depth when possible. Perl scripts might wish to employ Image-Pngslimmer which allows some dynamic optimization.
The current version of IrfanView can use PNGOUT as an external plug-in, obviating the need for a separate compressor.
Since icons intended for Windows Vista and later versions may contain PNG subimages, the optimizations can be applied to them as well. At least one icon editor, Pixelformer, is able to perform a special optimization pass while saving ICO files, thereby reducing their sizes.
|
||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||
